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(57) Abstract: An arrangement 
and a method is provided for 
discovering candidate access 
routers in a mobile IP (Internet 
Protocol) network to enable 
seamless IP handover of a mobile 
node between access routers. 
A server element (19), which is 
separate from the access routers 
(11, 12) and the mobile node 
(MN), is provided with access 
router information relating to 
one or more access routers and 
with information identifying the 
access router serving the mobile 
node and reachability information 
about one or more access routers 
other than the serving access 
router that are within reach to 
the mobile node. The address of 
at least one of said one or more 
access routers within reach to the 
mobile node is determined in the 
server element on the basis of the 
provided information. 
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Candidate access router discovery 

FIELD OF THE INVENTION 

[0001] The invention relates to mobile telecommunication networks, 
and more particularly to discovering candidate access routers in a mobile IP 
5 (Internet Protocol) network to enable seamless IP handover of a mobile node 
between access routers. 

BACKGROUND OF THE INVENTION 

[0002] One of the targets in the development of telecommunication 
networks is to provide the user with an IP service, i.e. access to the Internet 

10 through an access network. The basic IP concept does not support the mobility 
of the user, and therefore, a mobile IP protocol has been introduced by the 
Internet Engineering Task Force (IETF) in order to enhance the mobility in the 
Internet. Mobile IP enables routing of IP datagrams to mobile nodes independ- 
ently of the point of attachment in the sub-network. In the basic IP, the IP ad- 

15 dresses are assigned to network interfaces in dependence on their physical 
location, which prevents the user (the mobile node) from keeping its address 
while moving over different Internet sub-nets, i.e. while changing the physical 
interface. 

[0003] Mobile node (MN) refers to an IP node that is capable of 
20 changing its point of attachment from one network or sub-network to another. 
A mobile node may change its location without changing its IP address; it may 
continue to communicate with other Internet nodes at any location using its 
(permanent) IP address. When a mobile node visits a foreign network, a care- 
of-address (C/O-address) is temporarily assigned to the mobile node. The IP 
25 datagrams addressed to the mobile node are forwarded to this care-of- 
address. 

[0004] A critical issue for the success of next generation mobile 
networks is the ability of seamless IP-layer mobility. Seamless mobility is the 
ability to hand a mobile node (MN) over from one (old) access router (AR) to 

30 another (new) access router with minimal service disruption. An access router 
refers to an access network router residing on the edge of an access network 
and connected to one or more access points (AP), i.e. base stations. The ac- 
cess points may be of different technology. An access router offers IP connec- 
tivity to mobile nodes, acting as a default router to the mobile nodes it is cur- 

35 rently serving. 
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[0005] Discovering neighboring access routers within the access 
router's proximity is considered an important part of the ability of providing 
seamless handovers in IP based mobile networks. Mechanisms for realizing 
protocols to discover neighboring access routers and their capabilities to facili- 
5 tate seamless handovers have been proposed in e.g. [1] D. Trossen et al., "A 
Dynamic Protocol for Candidate Access Router Discovery", Work In Progress, 
IETF Internet Draft, October 2002, and D. Funato et al., "Geographically Adja- 
cent Access Router Discovery Protocol", Work In Progress, IETF Internet 
Draft, December 2002. 

10 [0006] The selection of the target access router (TAR), i.e. the ac- 

cess router to which the mobile node is eventually handed over, is not defined 
in the context of candidate access router (CAR) discovery, albeit it is the sub- 
sequent action to any CAR discovery solution. However, this step is not within 
the scope of CAR discovery, as outlined in D. Trossen et al., "Issues in Candi- 

15 date Access Router Discovery for Seamless IP-level Handoffs", Work In Pro- 
gress, IETF Internet Draft, October 2002. 

[0007] According to prior art solutions, candidate access router dis- 
covery protocols are realized either in the access routers or in the mobile 
nodes or in both. A possible problem relating to prior art solutions is that ac- 

20 cess routers may belong to different network operators and, thus, operators 
have to reveal various confidential information, e.g. capability information, to 
other operators. Furthermore, when the logic controlling the candidate access 
router discovery has to be updated, it must be performed in each access router 
separately. On the other hand, if the candidate access router discovery proto- 

25 cols are realized solely in the mobile nodes, this might lead to an excessive 
data exchange over the wireless link. 

BRIEF DESCRIPTION OF THE INVENTION 

[0008] An object of the present invention is thus to provide a 
method and an apparatus for implementing the method so as to overcome the 
30 above problems or to alleviate the above disadvantages or at least to provide 
an alternative solution. 

[0009] The invention is based on the idea of provisioning of candi- 
date access router discovery functionality in an external server element, e.g. 
an application server (AS). Hence, the functionality is neither implemented in 
35 the mobile node nor in the access router, even though they may have a sup- 
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porting role in the candidate access router discovery procedure. 

[0010] According to one aspect of the invention, there is provided a 
method of discovering candidate access routers in a mobile IP (Internet Proto- 
col) network to enable seamless IP handover of a mobile node between ac- 
5 cess routers, the method comprising: providing a server element, which is 
separate from the access routers and the mobile node, with access router in- 
formation relating to one or more access routers; providing the server element 
with information identifying the access router serving the mobile node and 
reachability information about one or more access routers other than the serv- 

10 ing access router that are within reach to the mobile node; and determining, in 
the server element on the basis of the provided information, address of at least 
one of said one or more access routers within reach to the mobile node. 

[0011] According to another aspect of the invention, there is pro- 
vided an arrangement in a mobile IP (Internet Protocol) network comprising: a 

15 mobile node, a plurality of access routers providing access for mobile nodes to 
an IP network, and a server element, which is separate from the access 
routers and the mobile node, comprising access router information relating to 
one or more access routers; wherein the arrangement is configured to provide 
the server element with information identifying the access router serving the 

20 mobile node and reachability information about one or more access routers 
other than the serving access router that are within reach to the mobile node, 
and the server element is configured to determine, on the basis of the provided 
information, address of at least one of said one or more access routers within 
reach to the mobile node. 

25 [0012] According to yet another aspect of the invention, there is 

provided a server element in a mobile IP (Internet Protocol) network compris- 
ing a mobile node and a plurality of access routers providing access for mobile 
nodes to an IP network, wherein the server element is separate from the ac- 
cess routers and the mobile node, and wherein the server element is config- 

30 ured to receive access router information relating to one or more access 
routers; receive information identifying the access router serving the mobile 
node and reachability information about one or more access routers other than 
the serving access router that are within reach to the mobile node, and deter- 
mine, on the basis of the provided information, address of at least one of said 

35 one or more access routers within reach to the mobile node. 

[0013] Further scope of applicability of the present invention will be- 
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come apparent from the detaifed description given hereinafter. However, it 
should be understood that the detailed description and specific examples, 
while indicating preferred embodiments of the invention, are given by way of 
illustration only, since various changes and modifications within the spirit and 
5 scope of the invention will become apparent to those skilled in the art from this 
detailed description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] In the following the invention will be described in greater de- 
tail by means of preferred embodiments with reference to the accompanying 
10 drawings, in which 

[0015] Figure 1 is a simplified block diagram of a mobile IP tele- 
communication system according to an embodiment of the invention; 

[0016] Figure 2 is a flow diagram illustrating the candidate access 
router discovery protocol according to an embodiment; 
15 [0017] Figure 3 is a block diagram of a mobile IP telecommunication 

system according to an embodiment of the invention; 

[0018] Figure 4 is a block diagram of a mobile IP telecommunication 
system according to an embodiment of the invention; 

[0019] Figure 5 is a flow diagram illustrating embodiments of the in- 

20 vention; 

[0020] Figures 6, 7, 8 and 9 are signalling diagrams illustrating em- 
bodiments of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

[0021] The present invention can be applied to any mobile commu- 
25 nication system providing packet data services for mobile nodes within a de- 
fined service area, and it can be embodied in various forms. 

[0022] Figure 1 shows a simplified block diagram of a mobile IP 
telecommunication system according to an embodiment of the invention illus- 
trating only basic elements of the system. It is obvious to a person skilled in the 
30 art that the system shown in Figure 1 typically comprises numerous other ele- 
ments, which are not described in greater detail herein. 

[0023] The mobile communication system of Figure 1 comprises a 
mobile node MN in its current cell 17 of a current access point 14. The mobile 
node MN is an IP node that is capable of changing its point of attachment to 
35 the network. The access point 14 is a device that provides an access link to 
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the mobile node MN, typically a link layer (layer 2, L2) device with a radio 
transceiver (e.g. a base station). The cell 17 consists of a geographical area 
within which wireless communication between the access point 14 and the 
mobile node MN is possible. An access router 1 1 acts as an IP router for the 
5 access point 14 connecting it to an IP network 10, such as the Internet. One 
access router may be connected to one or more access points and one access 
network may comprise one or more access routers. An access point may be a 
separate physical entity or co-located with an access router. The mobile node 
MN is registered in cell 17 but can move to the coverage area of either cell 16 

10 or cell 18 and start communicating with access point 13 or 15 correspondingly. 
In Figure 1 the serving access router 11 is connected to the current access 
point 14 and to a second access point 13. Figure 1 also shows another access 
router 12 connected to the access point 15. In accordance with the present 
invention, the system of Figure 1 comprises a separate server element 19, e.g. 

15 an application server (AS) or a corresponding network element. In the following 
description the term application server should be understood broadly to refer to 
any network element performing the function described. The server element 19 
can be implemented as a computer unit having suitable software therein. The 
server element 19 is preferably connected to the system via the IP network 10 

20 as shown. 

[0024] Figure 2 shows a flow diagram outlining the different phases 
to be performed by the CAR discovery protocol according to the present plans 
by the Internet Engineering Task Force. It should be noted that the future final 
solution to be implemented may be different from the one shown in Figure 2 

25 without this having any relevance to the basic idea of the present invention. 

[0025] The CAR discovery shown in Figure 2 starts with step 20, in 
which geographically adjacent access routers (GAAR) are discovered, and 
step 21, in which the capabilities of the geographically adjacent access routers 
are determined. The information determined in steps 20 and 21 together can 

30 also be referred to as physical neighborhood information or access router in- 
formation. Steps 20 and 21 take place prior to a handover of the mobile node 
from one access router to another. In the following step 22, layer 2 identifiers 
obtained by the mobile node are mapped to corresponding IP addresses and 
in step 23 a set of candidate access routers is determined. Step 24, namely 

35 the target access router selection, is also shown although it is not within the 
scope of the actual CAR discovery, as mentioned earlier. The CAR discovery 
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procedure is explained in greater detail in the following in connection with pre- 
ferred embodiments of the invention. 

[0026] According to an embodiment of the present invention, steps 
20 to 23 (or corresponding procedure) or at least some of them are performed 
5 in a separate server element. Preferably they are performed within an applica- 
tion server 19, which is located outside the network operator's realm. Thanks 
to this, the entire logic of CAR discovery will not reside inside any operator 
boundaries even though agreements between a service provider and opera- 
tors are still necessary for exchanging the appropriate information. This em- 

10 bodiment of the invention allows for inter-operator scenarios but also for differ- 
ent aspects of trust relationships (only between user and one service provider 
rather than between different operators). 

[0027] As to the provisioning of access router information 
(neighborhood information) to the application server 19, several alternative 

15 modes of implementation are possible. This information preferably comprises 
AR identifiers together with the identifiers of the access points that the access 
router serves. This information is used to perform the L2 to IP identifier map- 
ping. The format of the L2 identifiers depends on the specific link layer tech- 
niques used and has no relevance to the basic idea of the invention. Further- 

20 more, the information preferably comprises information about which other ac- 
cess routers are geographically adjacent, i.e. with which access points of other 
access routers does the access router have an overlapping coverage area. 
This information is used to determine the candidate access routers, i.e. the 
access routers that are potential candidates for handover at the time of the 

25 actual handover. 

[0028] Additionally, each piece of AR/AP information can be sup- 
plemented with capability information. This information can include capabilities 
of the AR/APs or other details (see e.g. [1]). Examples of capability information 
include bandwidths supported by the access router, dynamic loading condi- 

30 tions, security schemes, quality of service (QoS) capabilities, file formats, 
streaming media support, transmission technology, power levels, estimated 
signal range, service facilities, cost information, promotional information, ad- 
vertising information etc. This information is only required if the application 
server AS assists in the CAR determination process. If the CAR determination 

35 is entirely performed in the mobile node MN, this information is not required. 
There are several possibilities of obtaining this information: according to one 
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embodiment, the capability information is initially provided through the operator 
for each access router within the operator domain. According to another em- 
bodiment, the capability information is dynamically obtained by the application 
server AS through directly querying the access router for this information. In 
5 this case, the application server AS might contact the previous access router 
(ARi in Figure 3) for its capabilities. For this, a proper security association and 
trust relationship is assumed to exist between the operator and the application 
server AS. As one embodiment, a shared secret (shared between operator and 
the application server AS) might be used to identify the application server AS 

10 towards the access router, which in turn responds with the current set of capa- 
bilities. These capabilities are then stored appropriately in the application 
server's internal database as supplementary information to ARi. It is further 
possible that after the initial request, either the application server AS requests 
the capabilities in the future to refresh them (poll) or the access router sends 

15 the capabilities to the application server AS upon changes of the capabilities 
(push). According to yet another embodiment, at some time prior to the actual 
handover to a new point of attachment (at least the address of the new access 
router has to be available), the mobile node provides the application server 
with a handover trigger, containing the address of the new access router (or 

20 routers if several alternatives exist) and a list of capabilities of the new access 
router. If the mobile node is not aware of the capabilities of the new access 
router, it is also possible that the application server queries the new access 
router for the capability information upon receiving the handover trigger con- 
taining the address of the new access router. 

25 [0029] Different implementation modes can be used with respect to 

the provisioning of the abovementioned AR/AP identifiers and geographical 
information in the application server AS. 

[0030] According to one embodiment, provisioning of access router 
information (e.g. AR/AP identifiers, and the geographical information of each 

30 AR/AP) takes place through the network operator(s). For that, information that 
is required to be present in the application server AS is the mapping informa- 
tion of link layer identifiers, referred to as L2ID in the following, to IP addresses 
of the access router serving those link layer devices. Further, geographical 
information is required to be provided by the operator(s) to determine which of 

35 those access routers and access points are geographically adjacent. This in- 
formation is preferably provided to the application server by the operators 
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through service level agreements. However, this requires that the AP/AR loca- 
tions are well known to the operators, including the coverage areas. This is 
likely to be the case for engineered networks. Further, capability information, 
either statically or dynamically (depending upon the nature of the capability 
5 information), could be provided to the service provider by the operators. How- 
ever, this depends on whether or not capability information is retrieved through 
the application server AS or directly via the mobile node MN. The provisioning 
of the information can be performed at startup of the service within the applica- 
tion server AS, or it can be refreshed upon changes in the operator's network. 

10 The geographical information is preferably comprised of location and coverage 
area information of each AR/AP. This information is used to determine over- 
lapping coverage areas. However, this requires that the AP/AR locations are 
well known to the operators, including the coverage areas. This is likely to be 
the case for engineered networks. However, for many cases, this kind of in- 

15 formation is either not available or highly inaccurate, for instance for WLAN 
hotspot areas. 

[0031] According to another embodiment, provisioning of access 
router information does not require the operator to provide the exact AR/AP 
identifier information together with the geographical location information, and is 

20 therefore better suited for environments in which such information is not likely 
to be present, such as in WLAN hotspots. According to this embodiment, the 
AR/AP information is gathered through a learning mechanism described in 
more detail below. Hence, the mobile node MN sends the current and previous 
AR/AP identifier to the application server AS after a handover has occurred. 

25 With that information, the application server AS can determine that both ac- 
cess routers have overlapping coverage areas and are therefore geographi- 
cally adjacent. Further, the application server preferably stores the AR/AP in- 
formation for further mappings from L2 to IP for this particular access point. 
Referring to Figure 3, once the mobile node MN, connected to AR it moves 

30 from the coverage area 31 of ARi into the coverage area 32 of AR2, the mobile 
node MN sends (messages 101, 201, 301) the IP address of its previous ac- 
cess router, i.e. ARi. to the application server AS after the mobile node MN 
obtained connectivity with AR 2 , i.e. via the newly obtained connectivity with 
AR 2 . The information further contains the L2 identifier of the access point to 

35 which the mobile node MN was connected, i.e. which was served by ARi, and 
the IP address of AR 2 . This information, i.e. ARi's IP address and the access 
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point's 12 identifier, is added to application server's database information. If 
there exists capability information for this access router, provided through the 
operator as described above, the AR/AP information is appropriately added to 
this capability information. Further, the information of AR 2 is used to determine 

5 that ARi and AR 2 are geographically adjacent, i.e. that they have overlapping 
coverage areas. This inferred information is appropriately added to the data- 
base entry of ARi. Hence, the application server AS dynamically obtains in- 
formation about access router IP addresses together with the L2 identifiers of 
the access point that the access router is serving and IP addresses of adjacent 

10 access routers. This information is supplemented (if required) by the operator- 
provided capability information. According to this embodiment, the access 
router's IP address has to be present at the mobile node MN. Without this in- 
formation, the mobile node MN will not be able to send out packets. The proto- 
col, therefore, uses information (router's IP address) existing in the mobile 

15 node MN as the main information transferred in the protocol. In other words, 
the protocol does not assume additional capabilities to be present at the mo- 
bile node MN that are unique to the invention rather than re-uses information 
that is present in the mobile node MN anyway. 

[0032] Assuming that the AR/AP information, together with capabil- 

20 ity information, is present in the application server AS, provided through any of 
the above-mentioned embodiments, the CAR discovery preferably continues 
as follows. 

[0033] Once the mobile node MN is moving from a service area of 
one access router to the service area of another access router, as shown e.g. 

25 in Figure 3, and obtains reachability information about the other (one or sev- 
eral) AR/AP that is within reach to the mobile node, usually through receiving a 
link layer identifier within an access point L2 beacon that is served by the an- 
other (new) access router, the mobile node MN sends this reachability informa- 
tion to the application server AS together with the IP address of the currently 

30 serving access router. Note that the mobile node MN might also choose to 
provide a whole list of L2 identifiers (e.g. through collecting reachability infor- 
mation over a time window period). Upon reception of this list of L2 identifiers, 
the application server AS uses the neighborhood information to map the L2 
identifiers to the appropriate IP addresses of the serving access router. In 

35 other words, the mobile node MN detects the presence of certain access 
points, e.g. through receiving link layer information (beacon) from the new ac- 
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cess point (in Figure 4, the beacons of the access points (not shown) served 
by ARt and AR 3 are received by the mobile node MN, i.e. access routers ARi 
and AR 3 are within reach to the mobile node in addition to the serving access 
router AR 2 ). It is assumed that this information contains the L2 identifier of the 
5 access point. It is further assumed that the beacon does not contain the IP ad- 
dress of the access router that serves this access point. Note that there could 
be multiple access points that the mobile node MN could listen to (possibly 
over different radio interfaces) as shown in the example of Figure 4 showing 
the corresponding coverage areas 31, 32 and 33 of the access routers AR 1t 

10 AR 2 and AR 3 . The mobile node MN now sends a message to the application 
server AS (messages 1 1 1 , 21 1 and 31 1 in Figure 4) that contains the L2 identi- 
fier of the access point. Note that the message might also contain a list of 12 
identifiers in case that the mobile node MN received several beacons, as in the 
example of Figure 4. The message further includes the IP address of the ac- 

15 cess router that currently serves the mobile node MN, e.g. AR 2 in the example 
of Figure 4. Upon reception of the message, the application server AS uses its 
infernal database to map the L2 identifier(s) onto the IP address(es) of the ac- 
cess router(s) that serves the particular access point(s). The information stored 
in the application server's database allows for such kind of mapping due to the 

20 geographical adjacency information (e.g. either the geographical posi- 
tion/coverage information or the learned adjacency information). The applica- 
tion server AS compiles a list of IP addresses that corresponds to the list of 
provided L2 identifiers and sends this information back to the mobile node MN 
(messages 411, 511 and 611 in Figure 4). With this, the mobile node MN ob- 

25 tains knowledge of the IP addresses of the access routers that serve the ac- 
cess points from which it received the beacons. 

[0034] For the implementation of the actual CAR determination, dif- 
ferent modes for implementation are possible as well. According to an em- 
bodiment, the CAR determination is entirely performed in the mobile node MN, 

30 whereby the result of the L2 to IP mapping is directly sent back to the mobile 
node MN, which then in turn uses the address information for further purposes, 
e.g., requesting the capability information directly from the access router and 
performing the selection of an appropriate TAR. According to another embodi- 
ment, the capabilities of the access routers, which are mapped as described 

35 above, are included in the message 411 of Figure 4, i.e. in the response mes- 
sage of the application server. According to another embodiment, the mobile 
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node MN provides the application server AS with its requirements prior to (or 
together with) the mapping request, the list of CARs is determined within the 
application server AS through mapping of requirements onto capabilities (if 
available in the AS). The list of CARs is then eventually provided back to the 
5 mobile node MN. According to yet another embodiment, the capabilities of in- 
terest are provided back to the mobile node MN rather than revealing the re- 
quirements to the application server AS. In this case, the capabilities of interest 
have been provided to the application server AS from the mobile node MN be- 
fore the mapping was requested. This information is then used upon reception 

10 of message 311 in Figure 4 within the application server AS to be matched 
against the capabilities of each access router which serves at least one of the 
access points the MN heard. The application server AS then sends the 
mapped IP address back to the mobile node together with the capabilities of 
interest that were found. The implementation of the transfer of mobile node's 

15 capabilities of interest or mobile node's requirements from the serving access 
router to the new access router has no relevance to the basic idea of the in- 
vention. However, e.g. techniques presented in Kempf et al., "Problem De- 
scription: Reasons For Performing Context Transfers Between Nodes in an IP 
Access Network", IETF RFC (Request For Comments) 3374, September 2002, 

20 are suitable for this. For the last of above-mentioned embodiments relating to 
the capability handling, the final TAR selection can also be realized in the ap- 
plication server. For that, a policy is preferably specified how to determine a 
final candidate out of the set of possibly several CARs that is determined 
through matching the mobile node's requirements with the access router's ca- 

25 pabilities. How this policy is implemented and specified has no relevance to the 
basic idea of the invention. 

[0035] The specific format of the messages used in the various em- 
bodiments of the invention has no relevance to the basic idea of the invention. 
However, the usage of ICMP (Internet Control Message Protocol) messages or 

30 options together with TLV (type/length/value) or XML (extensible markup lan- 
guage) formatted content can be used, for example. Furthermore, the func- 
tionality within the application server can be implemented entirely on applica- 
tion level. 

[0036] In the embodiments of the invention described above, the 
35 mobile node MN has assisted the application server in the candidate access 
router discovery. It is, however, also possible that the access router assists the 
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application server. This embodiment of the invention is described in more de- 
tail in the following. 

[0037] According to an embodiment of the invention, the application 
server is known to each access router prior to performing the CAR discovery in 
5 the sense that the IP address and appropriate port information is known prior 
to the CAR discovery. Although each access router preferably has a unique 
server to be used for CAR discovery, it is feasible to introduce several servers 
within a domain, e.g. for load sharing. It is further assumed that appropriate 
security associations are present. Further, it is assumed that the application 

10 server maintains a Physical Neighborhood List (PNL) for each access router it 
serves (see e.g. [1] for possible implementation alternatives). The PNL pref- 
erably contains GAAR's IP addresses, the L2 identifiers, the capabilities for 
each GAAR, and an associated lifetime. In addition to this, the PNL has asso- 
ciated access router IP address, access router's L2 devices, and access router 

15 capabilities. It is not relevant to the basic idea of the invention how the access 
router's information has been obtained. A simple push to the server at startup 
of each access router or manual configuration are examples of possible ways 
for implementation. 

[0038] Referring to Figure 5, in step 51 , the access router sends 

20 GAAR information, i.e. the GAAR's IP address, to the application server. It has 
no relevance to the present invention how the GAAR information is obtained at 
the AR. However, mechanisms such as proposed in [1] can be used, for ex- 
ample. In addition, the access router can implement a cache containing the 
recently signalled GAAR identifiers. With this cache, the signalling to the appli- 

25 cation server is minimized, i.e. only new GAARs are signalled. If the GAAR has 
not yet been in the access router's PNL (stored in the application server), the 
server engages in a capability exchange with the GAAR in step 52 by sending 
a capability exchange message to the GAAR. The exact protocol used has no 
relevance to the basic idea of the present invention (possible implementation 

30 alternatives are disclosed in [1]). With these two steps, the application server 
eventually obtains knowledge of the physical proximity (stored in the PNL) of 
each access router it serves. The access router may request this information in 
step 53 by sending a PNL query request to the application server, which in turn 
sends the particular PNL back to the access router (step 54). The exact format 

35 of these messages has no relevance to the basic idea of the present invention. 
At the time of the mobile node's handover, the access router sends the list of 
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L2 identifiers of GAARs that have been detected by the mobile node MN to the 
application server in step 55. Optionally, the mobile node's requirements for 
the TAR selection might be contained in this message as well. How the L2 
identifiers are obtained has no relevance to the basic idea of the invention but 
5 again possible implementation alternatives are disclosed in [1]. The exact for- 
mat of this message has no relevance to the basic idea of the present inven- 
tion, either. In step 56, the application server maps the L2 identifiers to the ap- 
propriate IP addresses and determines the set of CARs for which it might use 
mobile node's requirements or some other criteria. 

10 [0039] Two different embodiments can be distinguished after the 

completion of step 56. Either the TAR selection is implemented entirely within 
the application server (steps 57a and 58a) or within the mobile node (steps 
57b and 58b). According to the first embodiment, the application server selects 
the TAR out of the set of CARs (step 57a), on the basis of e.g. some local se- 

15 lection algorithm. The identifier of the selected TAR is sent in step 58a to the 
access router. According to the second embodiment, the application server 
sends the list of CARs to the access router (step 57b), which in turn forwards 
this list to the mobile node (step 58b). The format of both messages has no 
relevance to the basic idea of the present invention. 

20 [0040] Since the PNL within the application server comprises a dis- 

tributed set of information, a maintenance and update mechanism is preferably 
realized to avoid or at least minimize inconsistencies of the set of data. For 
that, appropriate REFRESH and UPDATE messages can be implemented. 
The messages (REFRESH and UPDATE) are accordingly sent or forwarded to 

25 the application server. In a first embodiment, rather than sending the mes- 
sages from the access router to its GAARs, the message is sent to the applica- 
tion server, which in turn forwards them to all GAARs of this access router. In a 
second embodiment, upon reception of messages at the access router, the 
message is forwarded to the application server, which appropriately updates 

30 and maintains the PNL of the particular access router. 

[0041] The different embodiments of the invention described above 
potentially provide various advantages, which are briefly outlined below. The 
present invention allows for implementing the entire CAR discovery functional- 
ity outside of the network operator(s) realm(s). If the capability provisioning is 

35 implemented in the mobile node, there is no information required from the op- 
erator. This allows for a 3 rd party service provider approach for this kind of 
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network functionality. Such a 3 rd party approach is attractive for several rea- 
sons. The operators do not need to reveal information to other operators (since 
the entire logic resides in the application server which has a service level 
agreement with the operator, including the confidentiality aspect of the access 
5 router information). This secures the capability information exchange. If the 
CAR determination is implemented in the application server, the operators do 
not need to reveal information to the MN. Updating any kind of logic, in particu- 
lar selection logic for CAR determination, does not necessarily (depending on 
the embodiment used for the implementation) require changes in network ele- 

10 ments. The invention allows for several service providers, each of which could 
either serve different domains or could differentiate by the provided capability 
information. The present invention can also reduce the information that is ex- 
changed via the wireless link. 

[0042] As discussed already above, an ability of seamless service 

15 provisioning to mobile users is an important issue and the ability to handover a 
mobile node (MN) to a new access router (AR) with minimal disruption of IP 
connectivity is preferable. However, a service typically consists of more than 
mere IP-layer connectivity. The fact that a mobile node is able to exchange IP 
packets with the network does not necessarily mean that it can use a particular 

20 service. Hence, service disruption might still occur if the sen/ice-specific func- 
tionality is not relocated as the mobile node changes its point of attachment to 
the Internet. An embodiment of the invention described in detail below thus 
provides additional methods in order to provide seamless service to mobile 
users. It should be noted that the following embodiment and variations thereof 

25 can be combined with any of the embodiments of the invention described 
above. 

[0043] According to an embodiment of the invention, application 
context information of the mobile node is registered with the application server 
prior to changing the serving access router of the mobile node and, during the 

30 handover of the mobile node, the context information is used in the application 
server to invoke application specific actions. In other words, application context 
information is registered with the application server. The actual format of the 
specific application context information has no relevance to the basic idea of 
the invention. Next the application server is preferably provided with an identi- 

35 fier (e.g. an L2 identifier or an IP address if known) of the new access router to 
which the mobile node will connect at some point of time. After that the appli- 
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cation server is preferably provided with capability information of the new AR 
e.g. as described already earlier. This will lay ground for the appropriate han- 
dling of the service functionality relocation. Finally, the application server ex- 
tracts the relevant information from the registered application context informa- 
5 tion and the obtained capability information for the new AR realm and invokes 
appropriate actions, which are specific for the application, i.e. they are a matter 
of local implementation policy and thus have no relevance to the invention. 
This embodiment of the invention can be applied to various problems, e.g. 
transcoder relocation, security gateway relocation, location server relocation. It 

10 provides for seamless service provisioning without the necessity of a proper 
deployment in each access router. The central provisioning of seamless ser- 
vice provisioning also allows for faster upgrade of functionality compared to the 
upgrade within each access router. It also allows for a certain degree of free- 
dom in implementing certain seamless provisioning functionality, enabling dif- 

15 ferentiation of the service provider without opening interoperability problems. 
Further, this embodiment of the invention enables a service provider-driven 
approach to the problem of seamless sen/ice provisioning, i.e. dedicated ser- 
vice providers can be established that provide seamless continuation of certain 
services, hence enabling competition for this kind of functionality outside of the 

20 operator's domain. It also makes it possible to reduce the complexity of the 
mobile node since the relocation functionality is not required to be imple- 
mented at the mobile node. Since this functionality differentiates for each pos- 
sible application, the invention drastically reduces the mobile node's complex- 
ity by outsourcing this functionality to the application server. Examples of the 

25 implementation of this embodiment of the invention are given in the following. 

[0044] Figure 6 shows the message sequence chart according to 
one embodiment, in which the mobile node is aware of the capabilities of the 
new access router. In message 61 in Figure 6, the mobile node registers appli- 
cation context information with the application server. The application context 

30 information is stored within the application server for further usage. Examples 
for application context, among others, are media information, required re- 
sources (e.g. bandwidth), required service functionality (e.g. location informa- 
tion). At some time prior to the actual handoff to a new point of attachment, the 
mobile node provides the application server with a handoff trigger (message 

35 62), containing an identifier identifying the new access router and a list of ca- 
pabilities of the new access router (the MN is aware of these capabilities). 
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Based on the obtained information at handoff, i.e. new access router's identi- 
fier (from which the application server can derive the address of the access 
router, as described earlier in this application, if the identifier is not an address 
but e.g. an L2 identifier) and capabilities, and the registered application context 
5 of the mobile node, the application server takes appropriate actions (message 
63). It should be noted that message 63 might consist of a sequence of mes- 
sages, depending on the actual embodiment of the invention, i.e. actual ser- 
vice functionality that is relocated. The reasoning part in Figure 6 determines 
the actions to be taken. 

10 [0045] Figure 7 shows the message sequence chart according to 

another embodiment, in which the mobile node is not aware of the capabilities 
of the new access router. In message 71 in Figure 7, the mobile node registers 
application context information with the application server. The handoff event 
delivery (message 72) lacks the capability information since the mobile node is 

15 not aware of this information. The reasoning part, following message 72, de- 
termines the capability information that is required for the further actions. Mes- 
sages 73 and 74 in Figure 7 query the new access router for this capability 
information. Based on the obtained information, i.e. new access router's ad- 
dress and capabilities, and the registered application context of the mobile 

20 node, the application server takes appropriate actions (message 75 in Figure 
7). It should be noted that message 75 might consist of a sequence of mes- 
sages, depending on the actual embodiment of the invention, i.e. the actual 
service functionality that is relocated. The second reasoning part in Figure 7 
determines the actions to be taken. 

25 [0046] The exact format of presented messages as well as the ap- 

plication context format has no relevance to the basic idea of the invention. For 
example, appropriate ICMP or UDP (User Datagram Protocol) messages can 
be used. 

[0047] According to one embodiment of the invention, a pro-active 
30 allocation or relocation of application-specific resources can be provided. This 
is preferably implemented through marking application context information that 
is supposed to be allocated proactively during registration of the context (mes- 
sage 81 in Figure 8). The actions taken are then appropriately divided into pro- 
active and commitment actions. The mobile node delivers the identifier of the 
35 new access router to the application server prior to the actual handoff (shown 
in Figure 8 as message &V). The application server implements the pro-active 
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actions (message 81" in Figure 8) prior to the actual handoff. At the time of 
handoff, message 82 and subsequent messages are implemented similar to 
the non-proactive embodiment described above, implementing the commit- 
ment actions to be taken. According to another embodiment of the invention, 
5 shown in Figure 9, the capabilities of the new access router are obtained (i.e. 
messages 91" and 91"' in Figure 9) after receiving message 91' (correspond- 
ing to message 81') and taking the pro-active actions in message 91"" of Fig- 
ure 9. Messages 91, 92, 93, 94 and 95 correspond to messages 71, 72, 73, 74 
and 75, respectively. 

10 [0048] These embodiments of the invention can be applied to solv- 

ing various problems, such as transcoder relocation, security gateway reloca- 
tion, location server relocation, or web proxy redirection. These kind of imple- 
mentations are considered obvious to a person skilled in the art. However, as 
one possible example, a location server embodiment is outlined in the follow- 
15 ing. The mobile node registers the need of a location server for supplementary 
information to the provided service with the application server (message 71 in 
Figure 7). Upon handoff, the mobile node sends the identifier of the new ac- 
cess router to the application server (message 72 in Figure 7). If the domain of 
the application router has changed compared to the previous one (checked in 
20 the first reasoning part, e.g. based on the IP subnet information), the capabili- 
ties of the new access router are requested to obtain a location server address 
(messages 73 and 74 in Figure 7). If there is no location server information 
available at the new access router, the application server discovers the loca- 
tion server in the new domain (e.g. through using SLP), and takes appropriate 
25 actions for the continuation of the session (message 75 in Figure 7), e.g. pro- 
viding the location server address to the mobile node and core network. It 
should be noted that the situation according to Figure 6 can be realized 
through omitting the capability request (messages 73 and 74) and either issu- 
ing the discovery of the location server directly or obtaining the location server 
30 address through the new access router's capabilities (delivered through mes- 
sage 62 in Figure 6). 

[0049] An appropriate handling of the application context informa- 
tion is preferable in the application server. If the application server needs to 
contact other network elements for setting up the appropriate service environ- 
35 ment for the arriving mobile node, some protocol, such as SIP (Session Initia- 
tion Protocol), can be used. The handoff event can be generated through a 
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modification in the mobile IP stack of the mobile node, in which the new access 
router identifier (obtained through e.g. Router Solicitation message) is deliv- 
ered either directly to the application server or to the application layer in the 
mobile node (if handoff event delivery is implemented on the application layer). 
5 It should be noted that the handoff trigger and/or the capability information 
could be provided to the application server by the access router or in some 
other manner. 

[0050] It will be obvious to a person skilled in the art that, as the 
technology advances, the inventive concept can be implemented in various 
10 ways. The invention and its embodiments are not limited to the examples de- 
scribed above but may vary within the scope of the claims. 
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CLAIMS 

1. A method of discovering candidate access routers in a mobile IP 
(Internet Protocol) network to enable seamless IP handover of a mobile node 
between access routers, characterized in that the method comprises: 
5 providing a server element, which is separate from the access 

routers and the mobile node, with access router information relating to one or 
more access routers; 

providing the server element with information identifying the access 
router serving the mobile node and reachability information about one or more 
10 access routers other than the serving access router that are within reach to the 
mobile node; and 

determining in the server element, on the basis of the provided in- 
formation, address of at least one of said one or more access routers within 
reach to the mobile node. 
1 5 2. The method of claim ^characterized in that the informa- 

tion identifying the access router serving the mobile node is the IP address of 
the access router. 

3. The method of claim 1, characterized in that the address 
is an IP address. 

20 4. The method of any one of claims 1,2 or 3, characterized 

in that the reachability information comprises link layer identifiers relating to 
said one or more access routers within reach to the mobile node. 

5. The method of any one of claims 1 to 4, characterized in 
that the access router information comprises geographical information relating 

25 to the access router and mapping information for mapping of link layer identifi- 
ers relating to the access router to IP addresses. 

6. The method of any one of claims 1 to 5, characterized in 
that the information identifying the access router serving the mobile node is 
provided by the mobile node. 

30 7. The method of any one of claims 1 to 6, characterized in 

that the reachability information about one or more access routers within reach 
to the mobile node is provided by the mobile node. 

8. The method of any one of claims 1 to 5, characterized in 
that the information identifying the access router serving the mobile node and 
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the reachability information about one or more access routers within reach to 
the mobile node are provided by the access router serving the mobile node. 

9. The method of any one of claims 1 to 8 V characterized in 
that the method further comprises: 

5 transmitting the determined at least one address of said one or 

more access routers within reach to the mobile node from the server element 
to the mobile node; and 

using the at least one address in the mobile node to obtain capabil- 
ity information of said one or more access routers within reach to the mobile 
10 node. 

10. The method of any one of claims 1 to 8, characterized 
in that the method further comprises: 

transmitting the determined at least one address and capability in- 
formation of said one or more access routers within reach to the mobile node 
1 5 from the server element to the mobile node. 

11. The method of any one of claims 1 to 8, characterized 
in that the method further comprises: 

transmitting information about capabilities of interest from the mobile 
node to the server element; and 
20 transmitting the determined at least one address and capability in- 

formation about capabilities of interest of said one or more access routers 
within reach to the mobile node from the server element to the mobile node. 

12. The method of any one of claims 1 to 8, characterized 
in that the method further comprises: 

25 transmitting information about capability requirements from the mo- 

bile node to the server element; and 

transmitting the determined at least one address of one or more ac- 
cess routers within reach to the mobile node having capabilities matching the 
capability requirements from the server element to the mobile node. 

30 13. The method of any one of claims 1 to 12, characterized 

in that the access router information is provided to the server element by one 
or more network operators. 

14. The method of claim 13, characterized in that the ac- 
cess router information comprises capability information. 

35 15. The method of any one of claims 1 to 12, characterized 

in that the access router information is provided to the server element by send- 
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* ing information relating to the previous and new access router from the mobile 

node to the server element when the mobile node moves from the coverage 
area of one access router to the coverage area of another access router. 

16. The method of any one of claims 1 to 12, characterized 
5 in that the access router information is provided to the server element by one 

or more access routers. 

17. The method of any one of claims 1 to 16, characterized 
in that the method further comprises: 

transmitting capability information about capabilities of one or more 
1 0 access routers from the mobile node to the server element. 

18. The method of any one of claims 1 to 16, characterized 
in that the method further comprises: 

transmitting capability information about capabilities of an access 
router from the access router to the server element. 
15 19. The method of claim 18, characterized in that the capa- 

bility information is transmitted from the access router in response to a query 
from the server element. 

20. The method of claim 18 or 19, characterized in that the 
capability information is transmitted at predetermined intervals. 
20 21. The method of claim 18, characterized in that the capa- 

bility information is transmitted if it changes. 

22. The method of any one of claims 1 to 21, characterized 
in that the method further comprises: 

registering application context information on the mobile node with 
25 the server element prior to changing the serving access router of the mobile 
node and; 

using the context information in the server element to invoke appli- 
cation specific actions during the handover of the mobile node. 

23. An arrangement in a mobile IP (Internet Protocol) network com- 

30 prising: 

a mobile node (MN); and 

a plurality of access routers (11, 12) providing access for mobile 
nodes to an IP network (10); c h a r a c t e r i z e d in that the arrangement 
further comprises: 
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a server element (19), which is separate from the access routers 
and the mobile node, comprising access router information relating to one or 
more access routers; and in that 

the arrangement is configured to provide the server element with in- 
5 formation identifying the access router serving the mobile node and reachabil- 
ity information about one or more access routers other than the serving access 
router that are within reach to the mobile node; and 

the server element (19) is configured to determine, on the basis of 
the provided information, address of at least one of said one or more access 
1 0 routers within reach to the mobile node. 

24. The arrangement of claim 23, characterized in that the 
information identifying the access router serving the mobile node (MN) is the IP 
address of the access router. 

25. The arrangement of claim 23 or 24, c h a r a c t e r i z e d in 
15 that the address is an IP address. 

26. The arrangement of claim 23, 24 or 25, c h a r a c t e r I z e d in 
that the reachability information comprises link layer identifiers relating to said 
one or more access routers within reach to the mobile node (MN). 

27. The arrangement of any one of claims 23 to 26, c h a r a c - 
20 t e r i z e d in that the access router information comprises geographical in- 
formation relating to the access router and mapping information for mapping of 
link layer identifiers relating to the access router to IP addresses. 

28. The arrangement of any one of claims 23 to 27, c h a r a c - 
t e r i z e d in that the mobile node (MN) is configured to provide the informa- 

25 tion identifying the access router serving the mobile node. 

29. The arrangement of any one of claims 23 to 28, charac- 
terized in that the mobile node (MN) is configured to provide the reachabil- 
ity information about said one or more access routers within reach to the mo- 
bile node. 

30 30. The arrangement of any one of claims 23 to 27, c h a r a c - 

t e r i z e d in that the access router serving the mobile node (MN) is config- 
ured to provide the information identifying the access router serving the mobile 
node and the reachability information about said one or more access routers 
within reach to the mobile node. 

35 31. The arrangement of any one of claims 23 to 30, c h a r a c - 

terized in that 
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the server element (19) is configured to transmit the determined at 
least one address of said one or more access routers within reach to the mo- 
bile node to the mobile node; and 

the mobile node (MN) is configured to use the at least one address 
5 to obtain capability information on said one or more access routers within 
reach to the mobile node. 

32. The arrangement of any one of claims 23 to 30, c h a r a c - 
terized in that 

the server element (19) is configured to transmit the determined at 
10 least one address and capability information of said one or more access 
routers within reach to the mobile node to the mobile node. 

33. The arrangement of any one of claims 23 to 30, charac- 
terized in that 

the mobile node (MN) is configured to transmit information about 
1 5 capabilities of interest to the server element; and 

the server element (19) is configured to transmit the determined at 
least one address and capability information about capabilities of interest of 
said one or more access routers within reach to the mobile node to the mobile 
node. 

20 34. The arrangement of any one of claims 23 to 30, charac- 

terized in that 

the mobile node (MN) is configured to transmit information about 
capability requirements to the server element; and 

the server element (19) is configured to transmit the determined at 
25 least one address of one or more access routers within reach to the mobile 
node having capabilities matching the capability requirements to the mobile 
node. 

35. The arrangement of any one of claims 23 to 34, charac- 
terized in that the access router information is provided to the server ele- 

30 ment (1 9) by one or more network operators. 

36. The arrangement of claim 35, characterized in that the 
access router information comprises capability information. 

37. The arrangement of any one of claims 23 to 34, c h a r a c - 
terized in that the mobile node (MN) is configured to send information re- 

35 lating to the previous and new access router to the server element (19) when 
the mobile node moves from the coverage area of one access router to the 
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coverage area of another access router thus providing the access router infor- 
mation to the server element. 

38. The arrangement of any one of claims 23 to 34, c h a r a c - 
t e r i z e d in that at least one access router is configured to provide the ac- 

5 cess router information to the server element (19). 

39. The arrangement of any one of claims 23 to 38, c h a r a c • 
terized in that the mobile node (MN) is configured to transmit capability 
information about capabilities of one or more access routers to the server ele- 
ment. 

10 40. The arrangement of any one of claims 23 to 38, charac- 

terized in that at least one access router is configured to transmit capabil- 
ity information about capabilities of the access router to the server element 
(19). 

41 . The arrangement of claim 40, characterized in that the 
15 at least one access router (11, 12) is configured to transmit the capability in- 
formation in response to a query from the server element (19). 

42. The arrangement of claim 40 or 41, characterized in 
that the capability information is transmitted at predetermined intervals. 

43. The arrangement of claim 40, characterized in that the 
20 access router is configured to transmit the capability information if it changes. 

44. The arrangement of any one of claims 23 to 43, c h a r a c - 
terized in that 

the mobile node (MN) is configured to register application context in- 
formation with the server element prior to changing the serving access router 
25 of the mobile node and; 

the server element (19) is configured to use the context information 
to invoke application specific actions during the handover of the mobile node. 

45. A network element in a mobile IP (Internet Protocol) network 
comprising a mobile node (MN) and a plurality of access routers (11, 12) pro- 

30 viding access for mobile nodes to an IP network (1 0), c h a r a c t e r i z e d in 
that the network element (19) is separate from the access routers and the mo- 
bile node, and in that the network element is configured to: 

receive access router information relating to one or more access 

routers; 
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receive information identifying the access router serving the mobile 
node and reachability information about one or more access routers other than 
the serving access router that are within reach to the mobile node; and 

determine, on the basis of the provided information, address of at 
5 least one of said one or more access routers within reach to the mobile node. 

46. The network element of claim 45, characterized in that 
the information identifying the access router serving the mobile node is the IP 
address of the access router. 

47. The network element of claim 45 or 46, c h a r a c t e r j z e d in 
1 0 that the address is an IP address. 

48. The network element of claim 45, 46 or 47, character- 
ized in that the reachability information comprises link layer identifiers relat- 
ing to said one or more access routers within reach to the mobile node (MN). 

49. The network element of any one of claims 45 to 48, c h a r a c - 
15 terized in that the access router information comprises geographical in- 
formation relating to the access router and mapping information for mapping of 
link layer identifiers relating to the access router to IP addresses. 

50. The network element of any one of claims 45 to 49, c h a r a c - 
terized in that the network element (19) is configured to receive the infor- 

20 mation identifying the access router serving the mobile node from the mobile 
node. 

51 . The network element of any one of claims 45 to 50, c h a r a c - 
terized in that the network element (19) is configured to receive the reach- 
ability information about said one or more access routers within reach to the 

25 mobile node (MN) from the mobile node. 

52. The network element of any one of claims 45 to 49, c h a r a c - 
terized in that the network element (19) is configured to receive the infor- 
mation identifying the access router serving the mobile node (MN) and the 
reachability information about said one or more access routers within reach to 

30 the mobile node from the access router serving the mobile node. 

53. The network element of any one of claims 45 to 52, c h a r a c - 
terized in that the network element (19) is configured to transmit the de- 
termined at least one address of said one or more access routers within reach 
to the mobile node (MN) to the mobile node. 

35 54. The network element of any one of claims 45 to 52, c h a r a c - 

terized in that the network element (19) is configured to transmit the de- 
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termined at least one address and capability information on said one or more 
access routers within reach to the mobile node (MN) to the mobile node. 

55. The network element of any one of claims 45 to 52, c h a r a c - 
t e r i z e d in that the network element (1 9) is configured to 
5 receive information about capabilities of interest from the mobile 

node; and 

transmit the determined at least one address and capability informa- 
tion about capabilities of interest of said one or more access routers within 
reach to the mobile node to the mobile node. 
1 0 56. The network element of any one of claims 45 to 52, c h a r a c - 

t e r i z e d in that the network element (19) is configured to: 

receive information about capability requirements from the mobile 

node; and 

transmit the determined at least one address of one or more access 
15 routers within reach to the mobile node having capabilities matching the capa- 
bility requirements to the mobile node. 

57. The network element of any one of claims 45 to 56, c h a r a c - 
t e r i z e d in that the network element (19) is configured to receive the access 
router information from one or more network operators. 
20 58. The network element of claim 57, characterized in that 

the access router information comprises capability information. 

59. The network element of any one of claims 45 to 56, c h a r a c - 
t e r i z e d in that the network element (19) is configured to: 

receive information relating to the previous and new access router 
25 to the network element from the mobile node when the mobile node moves 
from the coverage area of one access router to the coverage area of another 
access router; and 

store the received information. 

60. The network element of any one of claims 45 to 56, c h a r a c - 
30 t e r i z e d in that the network element (1 9) is configured to receive the access 

router information from one or more access routers (11, 12). 

61 . The network element of any one of claims 45 to 60, c h a r a c - 
t e r i z e d in that the network element (19) is configured to receive capability 
information about capabilities of one or more access routers from one or more 

35 mobile nodes (MN). 
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62. The network element of any one of claims 45 to 60, c h a r a c - 
t e r i 2 e d in that the network element (19) is configured to receive capability 
information about capabilities of the access router from one or more access 
routers (11, 12). 

5 63. The network element of claim 62, characterized in that 

the network element (19) is configured to send a capability information query to 
the access router. 

64. The network element of any one of claims 45 to 63, c h a r a c - 
t e r i z e d in that the network element (1 9) is an application server. 
10 65. The network element of any one of claims 45 to 64, c h a r a c - 

t e r i z e d in that the network element (1 9) is configured to 

receive application context information from the mobile node (MN) 

and; 

use the context information to invoke application specific actions 
1 5 during the handover of the mobile node. 
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